High Efficiency Video Coding (HEVC) is a new coding standard that has been developed in recent years. In the High Efficiency Video Coding (HEVC) system, the fixed-size macroblock of H.264/AVC is replaced by a flexible block, named coding unit (CU). Pixels in the CU share the same coding parameters to improve coding efficiency. A CU may begin with a largest CU (LCU), which is also referred as coded tree unit (CTU) in HEVC. In addition to the concept of coding unit, the concept of prediction unit (PU) is also introduced in HEVC. Once the splitting of CU hierarchical tree is done, each leaf CU is further split into one or more prediction units (PUs) according to prediction type and PU partition.
FIG. 1 illustrates an exemplary adaptive Inter/Intra video coding system according to HEVC standard. For Inter-prediction, Motion Estimation (ME)/Motion Compensation (MC) 112 is used to provide prediction data based on video data from other picture or pictures. Switch 114 selects Intra Prediction 110 or Inter-prediction data and the selected prediction data is supplied to Adder 116 to form prediction errors, also called residues. The prediction error is then processed by Transform (T) 118 followed by Quantization (Q) 120. The transformed and quantized residues are then coded by Entropy Encoder 122 to be included in a video bitstream corresponding to the compressed video data. When an Inter-prediction mode is used, a reference picture or pictures have to be reconstructed at the encoder end as well. Consequently, the transformed and quantized residues are processed by Inverse Quantization (IQ) 124 and Inverse Transformation (IT) 126 to recover the residues. The residues are then added back to prediction data 136 at Reconstruction (REC) 128 to reconstruct video data. The reconstructed video data are stored in Reference Picture Buffer 134 and used for prediction of other frames. However, deblocking filter 130 and other in-loop filter 132 (i.e., sample adaptive offset, SAO) are applied to the reconstructed video data before the video data are stored in the reference picture buffer.
Context-based adaptive binary arithmetic coding (CABAC) is a high efficiency entropy coding tool that has been widely used in advanced video coding such as H.264 and HEVC. For example, various syntax elements of the HEVC standard are coded in the CABAC mode, where entropy coding is applied to the binarized syntax elements adaptively based on context associated with an underlying syntax element. FIG. 2 illustrates an exemplary block diagram of the CABAC process. Since the arithmetic coder in the CABAC engine can only encode the binary symbol values, the CABAC process needs to convert the values of the syntax elements into a binary string using a binarizer (210). The conversion process is commonly referred to as binarization. During the coding process, the probability models are gradually built up from the coded symbols for the different contexts. The context modeler (220) serves the modelling purpose. During normal context based coding, the regular coding engine (230) is used, which corresponds to a binary arithmetic coder. The selection of the modelling context for coding the next binary symbol can be determined by the coded information. Symbols can also be encoded without the context modelling stage and assume an equal probability distribution, commonly referred to as the bypass mode, for reduced complexity. For the bypassed symbols, a bypass coding engine (240) may be used. As shown in FIG. 2, switches (S1, S2 and S3) are used to direct the data flow between the regular CABA mode and the bypass mode. When the regular CABAC mode is selected, the switches are flipped to the upper contacts. When the bypass mode is selected, the switches are flipped to the lower contacts as shown in FIG. 2
The JCT standardization body is currently in the process of developing the HEVC screen content coding (SCC) extension. In contrast to the conventional natural video with a continuous color tone, the screen content video often contain a few pilot colors and sharp edges and boundaries. A palette coding has thus been developed for HEVC SCC, as defined in JCTVC-T1005 (Joshi, et al., HEVC Screen Content Coding Draft Text 3, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 20th Meeting: Geneva, CH, 10-18 February 2015, Document: JCTVC-T1005).
In the current the HEVC SCC draft as defined in JCTVC-T1005, when the palette mode is selected to code a CU, a set of palette colors are employed to represent the pixel sample values in the CU. The set of palette colors is also called a palette table or simply a palette. The colors in the palette table are referenced by palette index values. A palette table has to be used for each CU, which will result in substantial amount data to be transmitted. In order to reduce the required data transmission associated with the palette table, the palette color values in the current CU are predicted from a set of palette predictors built from the previously coded CUs. For each palette entry, a binary flag (i.e., PalettePredictorEntryReuseFlag) is employed to indicate whether this palette color is re-used in the current CU.
FIG. 3 illustrates an example of palette predictor update process. The current palette prediction 310 comprises color indices and associated colors. Furthermore, there is a reuse flag field 320 associated with the palette predictor to indicate whether a color of the predictor is used by the current palette table 330. In this example, only two colors in the predictor are used by the current CU (i.e., colour0 and colour2). There are Nnew new colors (340) in the current CU. To update the palette predictor, the colors in the buffer need to be reordered to generate the updated palette predictor 350.
The values of PalettePredictorEntryReuseFlag are coded by run length coding in order of the predictor index values. The re-use flags are represented in run-lengths, where each run length indicates the number of the consecutive re-use flags with PalettePredictorEntryReuseFlag equal to 0. FIG. 4 illustrates an example of run-length coding for palette reuse flags, where an Escape code with the value equal to 1 is used to indicate the last zero-run, and run-length values for zero-runs having run-length values equal to or larger than the EC code value are increased by 1. The coded run length are binarized using the Ex-Golomb Rice code with K=0.
It is desirable to develop methods for further improving the coding efficiency associated with the run length associated with the re-use flags.